開発チームリーダーとしてやってきたことのふりかえり #devio2023

DevelopersIO 2023のビデオセッションにて「開発チームリーダーとしてやってきたことのふりかえり」というテーマで発表をしました。私が開発チームリーダーを数年続けたなかでの学びをふりかえった内容となります。

DevelopersIO 2023

#チーム開発

#ふりかえり

野村啓一

2023.08.21

この記事は公開されてから1年以上経過しています。情報が古い可能性がありますので、ご注意ください。

概要

DevelopersIO 2023のビデオセッションにて「開発チームリーダーとしてやってきたことのふりかえり」というテーマで発表をしました。

私は prismatix という EC/CRM プラットフォームの注文・決済領域の開発チームでチームリーダーを務めています。

prismatix - ECサイトCRM基盤構築｜戦略的OMOを実現するAPIプラットフォーム

今回は、私が開発チームリーダーを数年続けたなかでの学びをふりかえった内容となります。この内容が皆さんのチーム開発において進め方の参考にできれば幸いです。

スライド

動画

アジェンダ

開発チームリーダーとして主にやってきたこと
私が考えるチームの理想形
チーム開発で直面した課題・取り組みとそこから得た学び
- 課題に対してどのようなことを取り組んできたか
- 取り組んだことから得た効果、学び
次に取り組むこと

開発チームリーダーとして主にやってきたこと

チームリーダーになるまで

2017年10月クラスメソッドJOIN
- prismatix 決済サービスの開発を担当
  - 最初はテックリードと一緒に２人３脚で開発
  - テックリードが離れ、他チームから決済サービスを担当する仲間が増えてチーム化
2019年7月〜
- 決済サービスのチームリーダーを担当
2021年7月〜
- 注文領域のサービスを担うチームと統合し、注文決済チームとして引き続きリーダーを担当

主な役割

注文決済領域の課題から、優先すべき開発タスクを計画・リード
顧客環境で発生した障害の司令塔、問い合わせやアラートの窓口
各タスクをメンバーに委譲
新規メンバーのオンボーディング、フォローアップ

などなど担当

私が考えるチームの理想形

チームメンバーが課題や顧客が求めているものを認識し、そのための対応をチーム内で協力してできること
- 各メンバー個人が↑まで出来ることではなく、「チーム内で協力しあって」できることが理想

開発チームリーダーを担当してから直面した課題

新しいチームメンバーへのケア
担当領域の説明が頻発して時間を取られる
個人スキルのサイロ化
リーダーとしての所作に迷い
想定以上に時間がかかるプロジェクト

他にもいろいろありましたが、主に上記の課題に対してチームで実践したこと、効果・学びになったことをまとめます。

新しいチームメンバーへのケア

悩み
- リーダーを担って以降、新しいチームメンバーが続々と入るようになった
  - チームメンバーに対するフォロー経験が当初は少なく、入ったばかりのメンバーが何をしてよいかわからない状態が続いてしまった
  - 逆に私がチームメンバーに対して、何をすれば立ち上がりをフォローできるか、当初は明確にできていなかった
取り組み①デイリーミーティングを実施
- それまではちゃんと実施していなかったが、チームメンバーと毎日話す機会として朝会・夕会（デイリーミーティング）を実施することにした
  - 朝会ではメンバーがその日やることを確認、困っていることがあればフォローする
  - 夕会ではその日予定してたことの状況、新しい困りごとを確認して明日以降の対応について決める
取り組み②スプリントごとにふりかえりを実施
- スプリントごとに以下をふりかえり、次のスプリントで実施するアクションを決める
  - 対応してよかったこと
  - 課題と感じていること
  - 次のスプリントでやること
取り組み③オンボーディング資料の整備
- オンボーディングとしてやるべきことを資料化
  - 初めてチームに入ったメンバーが最初にやること、準備することをまとめた
  - 新しいメンバーが入ったときはその資料をもとに説明することに
取り組んだことの効果
- メンバーと日々コミュニケーションを取る機会を作ることで、特に新しいメンバーが何に困ってるかを早めに把握できた
- ふりかえりをすることによって、メンバーが課題と感じることや学びと思えることが可視化できた
- オンボーディングの資料を整えたことで、私だけでなく他のメンバーも新規メンバーの受け入れができた

担当領域の説明が頻発して時間を取られる

悩み
- チームメンバーへのケアをしていく中で、メンバーが決済サービスそのものの仕様の理解に苦しんでいる
- 顧客や社内の他チームからも仕様の問い合わせが尽きない
  - 自分やチームが本来開発にあてる時間も割いてしまっている
取り組み : 担当領域の説明資料を作った
- 会社ブログやイベントで決済のシステムについて説明
取り組んだことの効果
- 担当領域の仕様をより一般向けに説明できる形にしたことで、チーム内外に説明しやすくなった
- この資料はそのまま、新しく入ってきたメンバーへのオンボーディングとして利用できた
残っている課題
- 元々の悩みだった問い合わせが減ったかというと、そうでもない
- 個人のスキルに依存していることがまだ残っている
  - 利用する外部サービスごとの詳細仕様
  - 外部サービスを追加する上での決めごとなど

個人単位でスキルがサイロ化（属人化）

悩み
- 2021年にチーム編成が変わり、決済だけでなく注文領域のサービスも担当することになった
  - 元々いたチームの担当サービス以外の仕様理解が難しい
  - 顧客から問い合わせやアラートを受けても対応できるメンバーが限られる
    - 問い合わせが集中するとそのメンバーの負荷が一気に高くなる
取り組み : モブプログラミング
- 属人化解消の一環としてモブプログラミングの導入を検討
  - [参考]チームにモブプログラミングを導入してみた | DevelopersIO
  - 狙い
    - チームのフロー効率向上
    - 知識・スキルのメンバーへのトランスファー
    - レビュースピード向上
- モブプロ講座を外部の講師に頼んで開いてもらう
  - 試しにチームの課題の中で1日数時間モブプロのやり方を導入してみた
取り組んだことの効果（良い点）
- 知識あるメンバーからの指摘をその場ですぐにもらうことで学びになることはあった
- その日やること、ゴールを共有する習慣がついた
取り組んだことの効果（辛かった点）
- 反面、メンバーによってはモブプロでつらいと感じる点はあった
  - オンラインで大人数で自分の作業を見られているという感覚
  - 取り組む課題に対する知識があるメンバーに質問が集中してメンバーが対応に追われた
  - しばらく目に見えた成果が見えないため、将来的に狙い通りの効果が出てくるのかという不安
取り組みを振り返った学び
- 1日必ずモブプロを実施することはやめて、必要に応じてメンバーを募り都度実施することにした
- メンバーからの声やチームでのふりかえりで早めに課題に気づき、方針を変更できたことが良かった
残っている課題
- 元々の悩みだった属人化についてはまだ解決に至っていない
- 私自身も新たな領域で対応すべき課題に対して判断に迷うことが増えてきた

リーダーとしての所作に迷い

悩み
- 対象領域が増えた中で、対応すべきことの判断に迷うことが増えた
  - この課題は何ができていれば良いか？
  - 経験が少ない領域に対して問い合わせが来ていて、何を回答すれば良いか？
    - わかりそうなメンバーには他の対応を優先してもらいたいので、気軽に聞けないことも
取り組み : マネージャーと 1on1
- マネージャーに 1on1 を直訴。自分の不明確なところや対応に自信ないところについて壁打ち相手となってもらい、相談を繰り返した
  - 細かくフィードバックもらうことでマネージャーの期待と自分の考えのズレを修正していった
取り組んだことの効果・学び
- 自信がないところを都度マネージャーとの話し合いの中で明確にしてもらい、マネージャーとの認識が合った状態でチームへの方針展開など進められた
- メンバーも同様に抱え込みすぎないように、こちらから 1on1 を提案
  - メンバーのやりたいことや不明瞭なところをヒアリングして、メンバーの意見を元にしたチーム開発の改善にも活かせた
  - リーダーである自分が相談のアクションを適宜取っていったことにより、チーム内でも「相談」に対するハードルは下がった
- 相談に乗ってくれる方の時間も有限、ということを忘れずに
  - 課題に対する仮説・対応案を以て相談に望むと良い

想定以上に時間がかかったプロジェクト

悩み
- とある機能開発で、当初の見積もりよりも大幅に時間を使ってしまいスケジュール遅延が発生
- 顧客への早い提供を実現しようと、無理にスケジュールを詰めてしまった
- テストで確認すべき項目が想定以上に膨れ上がった
  - すべてを限られたスケジュール内で対応することが困難
取り組み①スコープの調整
- 該当機能の要望があった顧客とヒアリングして、スケジュールの調整や最低限何ができてるとよいかを決めた
  - 当初見積もった機能すべて対応せず、最低限必要な機能にスコープを絞って提供することにした
取り組み②他チームからヘルプ要員を入れた
- 開発マネージャーと相談の上、他チームからヘルプを入れた
  - 該当機能の関連サービスに詳しい方に、一時的に手伝ってもらった
  - 膨大なテストケースに対応するため開発できるメンバーを増やして分担してもらった
    - 予めテスト要件が固まっており分担が可能なレベルまで作業を落とし込んでいたため、一時的に人を増やすことで対応できた
取り組み③プロジェクト完了のタイミングでふりかえり
- 数ヶ月にも及ぶ期間をその開発に要したため、タイムラインを利用したふりかえりを実施
  - [参考] タイムラインを使って、振り返りの材料をうまく集めよう - freee Developers Hub
  - 時系列でこのとき何をしていたか、何が問題だったか、何が功を奏したかなど関係者間でふりかえった
取り組んだことの学び
- プロジェクト初期の段階で達成条件や開発ボリュームが不明瞭なまま進めていたことが要因の一端としてあった
  - 不明瞭なことが残ってる状態でスケジュールをコミットしない
  - 開発チーム外のステークホルダ（プロダクトオーナーや顧客のサポート担当など）と課題のゴールや不明瞭な点を都度相談して合意することを意識できた
- 人員追加は効果的だったか？
  - 仕様理解ができていないメンバーを開発にそのままアサインするのは難しい
    - 対応内容や関連する仕様そのものが難しく、他のメンバーに説明・理解してもらうことが大変
  - テスト対応については各ケースが明確で説明・分担しやすかったこともあり、人員追加により早く対応できた

まだある悩み

個人単位でスキルがサイロ化（属人化）
- まだまだ個人単位でのスキルのサイロ化は改善はできていないと思っている
- 対応できる人の偏りが続き、ある領域に詳しい人がいなくなるとその領域に関連する課題の開発ができなくなる状態が続いている
チーム間で対応の目的・ゴールの共通認識ができていない
- 下記をチーム内で共通認識持つための仕組みがまだ整備できていない
  - 優先すべき内容を把握してリリース計画ができているか
  - ステークホルダと対応内容の合意が取れているか
  - 何が検証できていれば良いか

今後の取り組み

スキルのサイロ化に対する取り組み
- オンボーディング資料の整備
- 仕様勉強会
  - 特に知識が偏りがちなドメインに対して、定期的に関係者集めて勉強会を開く
- 対応履歴や相談した際の記録・履歴を残す
  - その対応に携わらなかったメンバーでも内容が把握できること
対応の目的・ゴールの共通認識に対する取り組み
- 開発チームから、顧客と接点が多いステークホルダとのコミュニケーションできる機会を増やす
  - 課題の目的・要件を双方で認識合わせる活動をしていく
- 対応する課題に対し、チーム内でキックオフミーティングを開き、ゴールの共通認識を作る
  - チームメンバーが不明瞭な点があれば、それを解消するためのタスクも作る
  - 何ができてるとよいか、何が検証できていればリリースOKとみなせるか？といった要件を先に明確にする